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(54) Method and apparatus for enabling access on a network switch 



(57) A data switch for network communications in- 
cludes a data port interface which supports at least one 
data port which transmits and receives data. The switch 
also includes a CPU interface, where the CPU interface 
is configured to communicate with a CPU, and a mem- 
ory management unit, including a memory interface for 
communicating data from the data port interface to the 
switch memory. A communication channel is also pro- 
vided, communicating data and messaging information 



between the data port interface, the CPU interface, the 
switch memory, and the memory management unit. The 
data port interface also includes an access control unit 
that filters the data coming into the data port interface 
and takes selective action on the data by applying a set 
of filter rules such that access to the switch is controlled 
by the set of filter rules. 
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Description 

BACKGROUND OF THE INVENTION 
FIELD OF THE INVENTION 

DESCRIPTION OF THE RELATED ART 

SSBB 

as 

of data by that switch. 
SUMMARY OF THE INVENTION 

r00071 The present invention is directed to a switch-on-chip solution for a switch, capable of using Ethernet Fast 
Set 1 gigaSd 10.000 Mbits/s Ethernet systems, wherein all of the hardware is disposed on * smg > mcrochip. 
^S^SSZ is also directed to methods employed to enable and control access on a «^ h - 
S The invention is therefore directed to a network switch for network 

nclud ng a data port interface, supporting a plurality of data ports transmrttmg and ^Jj^^*^^ 
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filters the data coming into the data port interface and takes selective action on the data by applying a set of filter rules 
such that access to the switch is controlled by the set of filter rules. 

[0009] The access control unit can be programmed by inputs from the CPU through the CPU interface. The data 
port interface may also include a filter mask table interface and a filter rules table thereupon, the set of filter rules being 
contained in the filter rules table. Additionally, the access control unit applies a filter mask to a packet incoming thereto, 
providing a fitter result, wherein the fitter result is applied to the filter rules in the filter rules table, and wherein action 
is taken on the data based upon the filtering result. Alternatively, the data port interface, the CPU interface, the memory 
management unit, the communications channel and the access control unit can all be implemented on a common 
semiconductor substrate. 

fast filtering processor. Additionally, the switch can control access to incoming data independent of the CPU interface, 
i.e. without communicating with the CPU, or in conjunction with communication with the CPU through the CPU interface! 
In either case, the filter rules of the network switch can be changed by the CPU based on access control list set in the 
CPU. Each filter rule of the set of filter rules can have an associated index and conflicting filtering results based on the 
application of the filter rules can be resolved through the associated indices of the filter rules. 
[0011] The invention is also directed to a method for handling data packets that includes placing incoming packets 
into an input queue. The incoming packet is then filtered through application of a set of filter rules by an access control 
unit in order to determine if the incoming packet should have access through the network switch. Then, the packet is 
discarded, forwarded, or modified based upon the application of the set of filter rules. The set of filter rules may be 
received through communication with a CPU through a CPU interface. The CPU can further update the filter rules of 
the set of filter rules based on an access control list set in the CPU, where the updating can include adding additional 
filter rules. Additionally, each filter rule of the set of filter rules can have an associated index, which can be used to 
resolve conflicting filtering results based on the application of the filter rules. 



25 BRIEF DESCRIPTION OF THE DRAWINGS 



[0012] The objects and features of the invention will be more readily understood with reference to the following 
description and the attached drawings, wherein: 

[0013] Fig. 1 is a general block diagram of elements of the present invention; 

[0014] Fig. 2 is block diagram of elements of the switch on chip of the present invention; 

[0015] Fig. 3 illustrates data flow in ingress in the switch of the present invention.; 

[0016] Fig. 4 is a block diagram of a fast filtering processor (FFP); 

[0017] Fig. 5 illustrates a series of steps which are used to program an FFP; 

[0018] Fig. 6 illustrates a network architecture that can be used with the present invention; 

[0019] Fig. 7 is schematic showing routers and network switch; and 

[0020] Fig. 8 illustrates voice over IP, where such access can be mediated through the methods of the present 
invention. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

[0021] The methods and apparatuses of the present invention enable traffic policing based on access control lists. 
The present invention supports traffic policing because of features built into structure of the network switch, described 
below, as well as intelligence built into software used with the network switch. The general structure of a network switch 
of embodying the present invention is discussed and then the general process of filtering data is described in more 
detail below. Next a brief overview of Access Control is described, the specific features of the present invention that 
are pertinent to traffic policing are discussed, and how these features are applied to some traffic policing applications 
are detailed. 

[0022] Fig. 1 illustrates a configuration wherein a switch-on-chip (SOC) 1 0, in accordance with the present invention, 
is functionally connected to external devices 11, a central processing unit (CPU) 52, gigabit Ethernet ports 15, and 
Ethernet ports 17. For the purposes of this embodiment, the Gigabit Ethernet ports 15, which are high speed Ethernet 
ports, are capable of operating at 1000 Mbps, but are also capable of operating at speeds ranging from 10 Mbps to 
100 Mbps. While the switch on chip is shown as being connected to Ethernet ports as well, embodiments of this 
invention are applicable to switches that connect only to Gigabit Ethernet ports. External devices 1 1 could include other 
switching devices for expanding switching capabilities, or other devices as may be required by a particular application. 
CPU 52 can be used as necessary to program SOC 10 with rules which are appropriate to control packet processing. 
However, once SOC 10 is appropriately programmed or configured, SOC 10 operates, as much as possible, in a free 
running manner without communicating with CPU 52. Because CPU 52 does not control every aspect of the operation 
of SOC 10, CPU 52 performance requirements, at least with respect to SOC 10, are fairly low. A less powerful and 
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therefore less expensive CPU 52 can therefore be used when compared to known network switches. ■ 
[0023] It should be noted that any number of gigabit Ethernet ports 1 5 or Ethernet ports 1 7 can be provided In one 
embodiment, 8 gigabit ports' 15 can be provided. Similarly, additional interconnect links to additional external devices 
11 and CPUs 52 mav be previded as necessary, 
s 002« SOC 10 includes a plurality of Ethernet Port Interface Controllers (EPIC) 20a. 20b, 20c : etc a plurality of 
G'raabit Port Interface Controllers (GPIC) 30a, 30b, etc., a CPU Management Interface Controller (CMIC) 40, a Common 
BufferMemory Pool (CBP)50, a Pipelined Memory Management Unit (PMMU) 70, including a Common Buffer Manager 

memory 12, which includes a Global Buffer Memory Poo. (GBP) 60. The CPS channel 80 compnses C channel 81 , P 

[00251 The CPS channel is also referred to as the Cell Protocol Sideband Channel, and is a 17 6bps ; channel which 
glues or interconnects the various modules together. As a.so illustrated in Figure 2 other h,gh 
can be provided, as shown as an extendible high speed interconnect. In one embod.ment of the invention, this inter- 
conneci Z be in the form of an interconnect port interface controller (.PIC) 90, which is capab.e of interfacing CPS 

*5 channel 80 to external devices 11 through an extendible high speed interconnect link 

[0026] As will be discussed below, each EPIC 20a, 20b, and 20c, generally referred to as EPIC 20, and GPIC 30a 
and 30b, generally referred to as GPIC 30, are closely interrelated with appropriate address resolufcon log* and layer 
three switching tab.es 21a. 21b. 21c. 31a, 31b, rules tables 22a. 22b. 22c. 31a, 31b, and VLAN table 23a, 23b, 23c 
31 a, 31b. These tables will be generally referred to as 21, 31, 22, 32, 23, 33. respectively. These tables, hke other 

20 tables on SOC 10, are implemented in silicon as two-dimensional arrays. 

002* In a preferred embodiment of the invention, each EPIC 20 supports 8 fast Ethernet ports 13, and switches 
paSs to and/or from these ports as may be appropriate. The ports, therefore, are connected to th ^twork medium 
Laxial twisted pair fiber, etc.) using known media connection technology, and communicates with the CPS channel 
8o" tel^ 

25 Media internal Interface (RM.I). which enables the direct medium connection to SOC 10. As « known ,n the art, auto- 
neqoUauo is an aspect of Fas Ethernet, wherein the networkiscapableof negotiating a highest communica . on speed 
2 1 and a destination based on the capabilities of the respective devices. The communica on speed 
carTvary, as noted previously, between 10 Mbps and 100 Mbps; auto negotiation capability, therefore, .s bu.lt d.rectly 

so iS Ch The ^resolution logic (ARL) and layer three tables (ARL/L3) 21 a, 21 b. 21 c ™f p ^* 

22c and VLAN tables 23a, 23b, and 23c are configuredto be part of or interface wrth the associated EPIC in an efficient 

2g ofTevel 2 address information can occur. Address resolution logic is utilized to assist ,n this task. Address 
35 aging squill in as a feature, in order to e.iminate the storage of address information which is no 

The EPIC also carries out layer 2 mirroring. A fast filtering processor (FFP) 141 (see F.g^3) s ■ncorporated into the 
EPIC, in order to accelerate packet forwarding and enhance packet flow. The ingress side of each EPIC and GPIC 
hasasignificantamountofcomplexitytobeabletoproperlyprocessasignificant number of d^n^ <* pacta* 
which may come in to the port, for linespeed buffering and then appropriate transfer to the egress. Functionally each 
40 port on eih module of SOC 10 has a separate ingress submodu.e 14 associated therewith. From an ,mp e^ntabon 
perspective, however, in order to minimize the amount of hardware implemented on the single-chip SOC 1 0, common 
Ldware elements in the silicon will be usedto implement a plurality of ingress submodules on each particular module^ 
The configuration of SOC 10 discussed herein enables concurrent lookups and filtering, and therefore, processing of 
up to 6 6 mln packets per second. Layer two lookups, Layer three lookups and filtering occur simultaneous^ to 

" £oTon^ 

or class of service (COS) function. Rerouting/scheduling of packets to be transmitted can occur as well as .head- 
line (HOL) blocking notification, packet aging, cell reassembly, and other functions assoc.ated wrth Ethernet port .nter- 

so '[0031] Each GPIC 30 is similar to each EPIC 20. but supports only one gigabit Ethernet port, and utilizes a port- 
Uif ic ARL table, rather than utilizing an ARL table whteh is shared with any other ports^ Add, .onarty. instead of an 
RMII each GPIC pott interfaces to the network medium utilizing a gigabit media independent interface (GMII). 
[0032] CMIC 40 acts as a gateway between the SOC 1 0 and the host CPU. The communication can be, for example, 
along a PCI bus, or other acceptable communications bus. CMIC 40 can provide sequential direct mapped accesses 

55 between the host CPU 52 and the SOC 1 0. CPU 52, through the CMIC 40, will be able to access numerous resources 
on SOC 10, including MIBcounters, programmable registers, status and control registers, configuration , registers ARL 
tables, port-based VLAN tables, IEEE 802.1q VLAN tables, layer three tables, rules tables CBP address lane I data 
memory as well as GBP address and data memory. Optionally, the CMIC 40 can include DMA support, DMA cha.nmg 
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and scatter-gather, as well as master and target PCI64. 

[0033] Common buffer memory pool or CBP 50 can be considered to be the on-chip data memory. In one embodiment 
of the invention, the CBP 50 is first level high speed SRAM memory, to maximize performance and minimize hardware 
overhead requirements. The CBP can have a size of, for example, 720 kilobytes running at 132 MHz. Packets stored 
in the CBP 50 are typically stored as cells, rather than packets. As illustrated in the figure, PMMU 70 also contains the 
Common Buffer Manager (CBM) 71 thereupon. CBM 71 handles queue management, and is responsible for assigning 
cell pointers to incoming cells, as well as assigning common packet IDs (CPID) once the packet is fully written into the 
CBP. CBM 71 can also handle management of the on-chip free address pointer pool ; control actual data transfers to 
and from the data pool, and provide memory budget management. 

In the preferred embodiment, GBP 60 is located off chip with respect to SOC 10. When located off-chip GBP 60 is 
considered to be a part of or all of external memory 12. As a second level memory, the GBP does not need to be 
expensive high speed SRAMs, and can be a slower less expensive memory such as DRAM. The GBP is tightly coupled 
to the PMMU 70, and operates like the CBP in that packets are stored as cells. For broadcast and multicast messages 
only one copy of the packet is stored in GBP 60. 

[0035] As shown in the figure, PMMU 70 is located between GBP 60 and CPS channel 80, and acts as an external 
memory interface. In order to optimize memory utilization, PMMU 70 includes multiple read and write buffers, and 
supports numerous functions including global queue management, which broadly includes assignment of cell pointers 
for rerouted incoming packets, maintenance of the global FAP, time-optimized cell management, global memory budget 
management, GPID assignment and egress manager notification, write buffer management, read prefetches based 
upon egress manager/class of service requests, and smart memory control. 

[0036] Fig. 3 illustrates some of the concurrent filtering and look-up details of a packet coming into the ingress side 
of a port of the switch. Fig. 3 addresses the application of filtering, address resolution, and rules application segments 
of SOC 10. These functions are performed simultaneously with respect to the CBP admission discussed above. As 
shown in the figure, packet is received at an input port of one of the EPIC 20 or GPIC 30. It is then directed to input 
FIFO 33. As soon as the first sixteen bytes of the packet arrive in the input FIFO 33, an address resolution request is 
sent to ARL engine 24 (step 2a); this initiates lookup in ARL/L3 tables 21 . 

[0037] If the packet has 802.1q Tag then the ARL Engine does the lookup based on 802.1q Tag in the TAG BASED 
VLAN TABLE. If the packet does not contain 802. 1q Tag then ARL Engine gets the VLAN based on the ingress port 
from the PORT BASED VLAN TABLE. Once the VLAN is identified for the incoming packet, ARL Engine does the ARL 
Table search based on Source Mac Address and Destination Mac Address. The key used in this search is Mac Address 
+ VLAN Id. If the result of the ARL search is one of the L3 Interface Mac Address, then it does the L3 search to get 
the Route Entry. If an L3 search is successful then it modifies the packet as per Packet Routing Rules. 
[0038] At step 2b, a Filtering Request is sent to an Access Control Unit (ACU) or a Fast Filtering Processor (FFP) 
27 as soon as first 64 bytes arrive in the Input FIFO. The outcome of the ARL search, step 3a, is the egress port/ ports 
the Class Of Service (COS), Untagged Port Bitmap and also in step 3b the modified packet in terms of Tag Header' 
or L3 header and L2 Header as per Routing Rules. In the following discussion, while the FFP is cited as performing 
the filtering process, it is understood that the ACU is also implicitly recited when access to the switch is being controlled. 
The FFP applies all the configured Filters and results are obtained from the RULES TABLE. 

[0039] The outcome of the Filtering Logic, at 3c, decides if the packet has to be discarded, sent to the CPU or, in 
3d, the packet has to be modified in terms of 802. 1 q header or the TOS Precedence field in the IP Header. If the TOS 
Precedence field is modified in the IP Header then the IP Checksum needs to be recalculated and modified in the IP 
Header. 

[0040] The outcome of FFP and ARL Engine, 31 , in 4a, are applied to modify the packet in the Buffer Slicer 32 
Based on the outcome of ARL Engine and FFP, 4b, the Message Header 28 is formed ready to go on the Protocol 
Channel 30. The Dispatch Unit 29 sends the modified packet over the cell Channel 80, in 5a, and at the same time in 
5b, sends the control Message on the Protocol Channel 80. The Control Message.contains the information such as 
source port number, COS, Flags, Time Stamp and the bitmap of all the ports on which the packet should qo out and 
Untagged Bitmap. 

[0041] FFP 27 is essentially a state machine driven programmable rules engine. The filters used by the FFP are 64 
(sixty-four) bytes wide, and are applied on an incoming packet; any offset can be used, however, a preferred embod- 
iment uses an offset of zero, and therefore operates on the first 64 bytes, or 512 bits, of a packet. The actions taken 
by the filter are tag insertion, priority mapping, TOS tag insertion, sending of the packet to the CPU, dropping of the 
packet, forwarding of the packet to an egress port, and sending the packet to a mirrored port. 
[0042] The filters utilized by FFP 1 41 are defined by rules table 22. Rules table 22 is completely programmable by 
CPU 52, through CMIC 40. The rules table can be, for example : 256 entries deep, and may be partitioned for inclusive 
and exclusive filters, with, again as an example, 128 entries for inclusive filters and 128 entries for exclusive filters. A 
filter database, within FFP 141 , includes a number of inclusive mask registers and exclusive mask registers, such that 
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the filters are formed based upon the rules in rules table 22, and the filters therefore essentially form a 64 byte wide 
mask or bit map which is applied on the incoming packet. 

[00431 If the filter is designated as an exclusive filter, the filter will exclude all packets unless there is a match. In 
other words the exclusive filter allows a packet to go through the forwarding process only if there is a filter match. If 
s there is no filter match, the packet is dropped. In an inclusive filter, if there is no match, no action is taken but the packet 
is not dropped. Action on an exclusive filter requires an exact match of all fitter fields. If there is an exact match with 
an exclusive filter therefore, action is taken as specified in the action field; the actions which may be taken, are dis- 
cussed above If there is no full match or exact of all of the filter fields, but there is a partial match, then the packet is 
dropped. A partial match is defined as either a match on the ingress field, egress field, or filter select fields. If there is 

proceeds through the forwarding process. The FFP configuration, taking action based upon the first 64 bytes of a 
packet enhances the handling of real time traffic since packets can be filtered and action can be taken on the fly. 
Without an FFP according to the invention, the packet would need to be transferred to the CPU for appropriate action 
to be interpreted and taken. For inclusive filters, if there is a fitter match, action is taken, and rf there is no filter match, 

is no action is taken; however, packets are not dropped based on a match or no match situation for inclusive fitters. 
[0044] In summary the FFP includes a filter database with eight sets of inclusive filters and eight sets of exclusive 
filters as separate filter masks. As a packet comes into the FFP, the filter masks are applied to the packet; in other 
words a logical AND operation is performed with the mask and the packet. If there is a match, the matching entries 
are applied to rules fables 22, in order to determine which specific actions will be taken. As mentioned previously, the 

20 actions include 802.1p tag insertion, 802.1p priority mapping, IP TOS (type-of-service) tag insertion, sending of the 
packet to the CPU, discarding or dropping of the packet, forwarding the packet to an egress port, and sending the 
packet to the mirrored port. 

[00451 Since there are a limited number of fields in the rules table, and since particular rules must be applied for 
various types of packets, the rules table requirements are minimized in the present invention by the present invention 
25 setting all incoming packets to be "tagged" packets; all untagged packets, therefore, are subjectto 802.1p tag insertion, 
in order to reduce the number of entries which are necessary in the rules table. This action eliminates the need for 
entries regarding handling of untagged packets. It should be noted that specific packet types are defined by various 
IEEE and other networking standards, and will not be defined herein. 

[0046] As noted previously, exclusive filters are defined in the rules table as filters which exclude packets for which 

30 there is no match; excluded packets are dropped. With inclusive filters, however, packets are not dropped in any 
circumstances. If there is a match, action is taken as discussed above; if there is no match, no action is taken and the 
packet proceeds through the forwarding process. Referring to Figure 4, FFP 27 is shown to include filter database 272 
containing filter masks therein, communicating with logic circuitry 271 for determining packet types and applying ap- 
propriate filter masks. When the packets are filtered based on flows, as discussed below, a flow monitor 273, is used 

35 to track the flows through the switch. After the filter mask is applied as noted above, the result of the application is 
applied to rules table 22, for appropriate lookup and action. It should be noted that the filter masks, rules tables, and 
logic, while programmable by CPU 52, do not rely upon CPU 52 for the processing and calculation thereof. After 
programming, a hardware configuration is provided which enables linespeed filter application and lookup. 
[0047] Referring once again to Fig. 3, after FFP 27 applies appropriate configured filters and results are obtained 

40 from the appropriate rules table 22, logic 271 in FFP 27 determines and takes the appropriate action. The filtering logic 
can discard the packet, send the packet to the CPU 52, modify the packet header or IP header, and recalculate any 
IP checksum fields or takes other appropriate action with respect to the headers. The modification occurs at buffer 
slicer 32 and the packet is placed on C channel 80. The control message and message header information is applied 
by the FFP 27 and ARL engine 24, and the message header is placed on P channel 80. Dispatch unit 29 coordinates 

*5 all dispatches to C channel, P channel and S channel. 

[0048] As noted previously, each EPIC module 20, GPIC module 30, PMMU 70, etc. are individually configured to 
communicate via the CPS channel. Each module can be independently modified, and as long as the CPS channel 
interfaces are maintained, internal modifications to any modules such as EPIC 20a should not affect any other modules 
such as EPIC 20b, or any GPICs 30. 

so [0049] As mentioned previously, FFP 27 is programmed by the user, through CPU 52, based upon the specific func- 
tions which are sought to be handled by each FFP 27. Referring to Figure 5, it can be seen that in step 1 7-1 . an FFP 
programming step is initiated by the user. Once programming has been initiated, the user identifies the protocol fields 
of the packet which are to be of interest for the filter, in step 17-2. In step 17-3, the packet type and filter conditions 
are determined, and in step 17-4, a filter mask is constructed based upon the identified packet type, and the desired 

55 filter conditions The filter mask is essentially a bit map which is applied orANDed with selected fields of the packet. 
After the filter mask is constructed, it is then determined whether the filter will be an inclusive or exclusive filter, de- 
pending upon the problems which are sought to be solved, the packets which are sought to be forwarded, actions 
sought to be taken, etc. In step 17-6, it is determined whether or not the filter is on the ingress port, and in step 17-7, 
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it is determined whether or not the filter is on the egress port. If the filter is on the ingress port, an ingress port mask 
is used in step 17-8. If it is determined that the filter will be on the egress port, then an egress mask is used in step 
17-9. Based upon these steps, a rules table entry for rules tables 22 is then constructed, and the entry or entries are 
placed into the appropriate rules table (steps 17-10 and 17-11). These steps are taken through the user inputting 
particular sets of rules and information into CPU 52 by an appropriate input device, and CPU 52 taking the appropriate 
action with respect to creating the filters, through CMIC 40 and the appropriate ingress or egress submodules on an 
appropriate EPIC module 20 or GPIC module 30. 

[0050] An illustrative system configuration is generally illustrated in Figure 6. In this configuration, two personal com- 
puters (PCs) 121 , each with network access capability, allow users 120 to exchange data with each other through an 

122. A general illustration of a configuration of the invention is shown in Fig. 7. Each of network switches 124, which 
are generally equivalent to the exemplary network switch (SOC 1 0) described above, which are positioned on the outer 
edge or boundary of IP network 122, and are configured to utilize the fast filtering processor (FFP) 141 to identify 
related packets and take appropriate actions upon the identified packets in order to facilitate transmission of the packets 
through the network. The fast filtering processor 141 of network switch 1 24 operates to apply the filter mask discussed 
above to the packet header of every packet coming through network switch 124. 

[0051] Upon applying the mask to the packet header, the remaining information is then compared to entries residing 
in rules table 22 located in the network switch 1 24. If a match is found between the masked information from the packet 
header and an entry in the rules table 22 of the network switch, then the fast filtering processor 141 takes an action 
upon the packet in accordance with a predetermined action field stored in the network switch. Alternatively, an exclusive 
filter scheme could be employed, wherein a no-match state triggered taking action in accordance with the action fields. 
Nonetheless, the actions corresponding to the predetermined action field may include changing or modifying the Layer 
2 priority associated with the packet, changing the type of service (TOS) associated with the packet, modifying the 
differentiated services code point (DSCP) associated with the packet, sending the packet to a queue for a predetermined 
Class of Service (COS), sending the packet to the CPU via the CPU interface, or discarding the packet, in addition to 
other switching actions. 

[0052] One application that is used on a network environment, that is of special interest to the access control of the 
present invention, is voice over IP (VOIP). When a voice conversation is transmitted through a data network, it must 
first be broken down in to small -pieces" of audio. This process is illustrated generally in Fig. 8. Each of these pieces, 
termed a voice packet or voice frame, consists of a very short duration, generally from 1 0 to 30 ms, of audio. A string 
of voice packets, which when assembled form a continuous audio stream, are generally compressed, linked together 
with a common packet header, and transmitted through the data network to the destination IP address. 
[0053] In discussing the access control of the present invention, the role of an access control list must be discussed. 
The access control features most pertinent to network switches are access permission and denial. Access permission 
is, in most cases, an exception to a general access denial policy. Likewise, access denial is an exception to a general 
permission. In the present invention, access control is enabled on a per flow basis. A traffic flow can be defined as 
traffic based on network addresses, application type and other criteria. 

[0054] In the present invention, commands can be implemented using the FFP to control access. The commands, 
and examples of using the commands, are based on the document Cisco IOS IP and IP Routing Command Interlace. 
The commands pertinent to the StrataSwitch are mostly about traffic policing. An access control list specifies the traffic 
that are allowed or denied access to the networking equipment. It consists of one or more access control commands. 
In the access controls that are relevant to the present invention, a command has the following format: 



45 



access-list <access-list identifier permit I deny <parameter> .... 
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[0055] The parameters specify what type of traffic is being access controlled, i.e. permitted or denied in the network. 
The traffic may be based on network address/subnet, application type, protocol type, etc. In the following table, the 
parameters that are most pertinent to permit or deny commands are described below: 



TABLE 1 



Command Parameters 


Descriptions 


<protocol> 


Layer III protocol in frame header or layer IV protocol in IP header 
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TABLE 1 (continued) 



Command Parameters 


Hag r- r 1 nt ift n Q 


< IP> 

<wild-card> 


specifies the network addresses in the ACL; <iP> specifies the !P address/subnet to 

• _j ... : n tk n o format ae a roni 1 1 CJ r IP aHHrP^^ SDSCifieS the 

be used' <wilu-C3ru>, in me same Tonnai as a reyuicii ir duuicaa, o^cwuw 
wildcard value of the IP address (0 = must match, FF = ignored); any ACL must have 
two such pairs, the first one for the access control for the packet origin, while the 
second one for the packet destination 


| any I 


mav replace anv <IP> <wild-card> pair: same semantics as FF.FF. FF.FF in the <wttd- 


precedence 

<precedence> 


precedence field in IP header 


tos <tos> 


type-of-service field in IP header 


<icmp-type> 


for an icmp message, the icmp-type field in IP payload, this parameter is specified 
In numeric (0-255) 


<icmp-code> 


for an icmp message, the icmp-code field in IP payload, this parameter is specified 

in nnmorir m-9^^^ 


<icmp-message> 


fnr an irmo messaae the combined icmp type and code fields. The icmp-message 
is specified in a mnemonic, which is translated to a value from 0 to 255. 


<iamp-type> 


for an igmp message, the IGMP type field in the IP payload 


eq <port> 


destination port number in TCP/UDP header 


established 


for a TCP packet, the ACK bit or RST bit in CODE BITS in TCP header 


eq <protocot> 


ACL is applicable to an application protocol <protocol> 


no-<protocol> 


no application protocol <protocol> allowed 


<time-range-id> 


ACL is only effective in a specified time range <time-range- id>, which is predefined 
in a time-range command. 



15 



20 



25 



30 



35 



[0056] As discussed above with respect to the FFP, the FFP will use each filter mask to mask out certam fields of 
the packet, and determine whether the masked out packet matches the relevant filter rules. The mask covers four of 
the first five 1 6-byte segments of the packet. If there is a match, some specific action will be taken. 
[0057] For instance, if the switch wants to capture all the packets of a particular application, like RTSP (Real-Time 
Streaming Protocol), the following filter mask will be used: 



0000 0000 0000 0000 0000 0000 0000 0000 
0000 0000 0000 0000 0000 0000 0000 0000 
0000 0000 0000 0000 FFFF 0000 0000 0000 
0000 0000 0000 0000 0000 0000 0000 0000. 



[0058] Every packet executed with this mask will only have bytes (0-based) 40 and 41 untouched. After the masking, 
the packet will be matched with all the rules associated with this mask, one of which has the value 0x022A (554 decimal) 
in bytes 40 and 41 , shown below: 



0000 0000 0000 0000 0000 0000 0000 0000 
0000 0000 0000 0000 0000 0000 0000 0000 
0000 0000 0000 0000 022A 0000 0000 0000 
0000 0000 0000 0000 0000 0000 0000 0000. 
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[0059] Thus if the packet is an RTSP packet, it will have value 554 in its TCP destination port field and result in a 
match. Packet classifications result in the matched packets receiving special processing. The two actions related to 
traffic policing are discarding a packet and explicitly switching a packet. 

[0060] The switch on chip of the present invention has a built-in mechanism to resolve filter rule conflicts Filtering 
conflict anses when there are two rules matching the same packet, while the two rules calling for two conflicting actions 
to be taken, such as discarding a packet and changing the packet's priority. When two rules match the same packet 
the action associated with the filter of a higher mask index (the FSEL field of the rule) is executed. With that in mind* 
the network administrator who implements Access Control must carefully order the filter masks such that conflict res- 
olution behaves as expected. 



the following applications are discussed in detail, the discussions of these applications should not be seen as limiting- 
rather the present invention can be used to enable access control in a variety of applications. In a LAN if the admin- 
istrator wants to disable all Web browsing traffic, i.e., no HTTP traffic can go through, a simple traffic denial is put into 
effect. 

[0062] To implement this access control, only one access control command is required. That command would have 
the form of: 



access-list 101 deny ip any any eq http. 



20 



[0063] The above access control requires one filter mask (Table 2) and one filter rule (Table 3) to enable this access 
list: 



25 



30 



Ingress 
Port Mask 


Egress Port 
Mask 


Filter Mask 


0 


0 


0000 0000 0000 0000 0000 0000 0000 0000 
FFFF 0000 0000 0000 0000 0000 0000 0000 
0000 0000 0000 0000 FFFF 0000 0000 0000 
0000 0000 0000 0000 0000 0000 0000 0000 



Table 2 



35 



40 



45 



Filter 
Select 


Action 


Filter Value 


0 


10 


0000 0000 0000 0000 0000 0000 0000 0000 
0800 0000 0000 0000 0000 0000 0000 0000 
0000 0000 0000 0000 0050 0000 0000 0000 
0000 0000 0000 0000 0000 0000 0000 0000 



Table 3 



50 



55 



[0064] This filter rule will match all packets that have 0x0800 at its Layer 2 Frame Protocol Field, which indicates an 
IP packet; and 0x0050 at its TCP/UDP destination port field, which is the Well-Known-Port (WKP) for HTTP message. 
The action for a rule match is to discard the packet, which is indicated by having bit 4 (the least significant bit being 
bit 0) set. This is specified by the value 0x1 0 in the ACTION field. 

[0065] In another application, the LAN owner or administrator may want to disable web access as in the previous 
example, but only during certain hours. The access control list thus requires a qualification, which is a time ranqe of 
that the access control list is in effect: 
time-range no-http 

periodic weekdays 8:00 to 1 8:00 

i 

access-list 101 deny tcp any any eq http time-range 

[0066] This command is implemented in conjunction with the CPU, which places the filter into the filter table at 08: 
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00 and removes it at 18:00 every weekday. The filter is the same as the one used in the previous example, but shows 
the expandability of the filtering process. 

[0067] In another example, the LAN administrator may want to deny all IP traffic, except ICMP traffic, originated from 
the subnet 1 92.1 68.3.xx. To implement this policy, the access control list consists of two commands and the following 
5 filter masks (Table 4) and filter rules (Table 5): 

access-list 102 deny ip 192.168.3.0 0.0.0.255 any 
access-list 102 permit icmo 192.168.3.0 0.0.0.255 any 



0 



Ingress 
Port Mask 


Egress 
Port Mask 


Filter Mask 


0 


0 


0000 0000 0000 0000 0000 0000 0000 0000 
FFFF 0000 0000 0000 0000 0000 0000 FFFF 
FF0O 0000 0000 0000 0000 0000 0000 0000 
0000 0000 0000 0000 0000 0000 0000 0000 I 


0 


0 


0000 0000 0000 0000 0000 0000 0000 0000 
0000 0000 0000 0000 0000 OOFF 0000 FFFF 
FFOO 0000 0000 0000 0000 0000 0000 0000 
0000 0000 0000 0000 0000 0000 0000 0000 


TABLE 4 


Filter Select 


Action 


Filter Value 


0 


10 


0000 0000 0000 0000 0000 0000 0000 0000 
0800 0000 0000 0000 0000 0000 0000 C0A8 
0300 0000 0000 0000 0000 0000 0000 0000 
0000 0000 0000 0000 0000 0000 0000 0000 


1 


2000 


0000 0000 0000 0000 0000 0000 0000 0000 
0000 0000 0000 0000 0000 0001 0000 C0A8 
0300 0000 0000 0000 0000 0000 0000 0000 
0000 0000 0000 0000 0000 0000 0000 0000 



TABLE 5 



40 [0068] This example illustrates the usage of conflict resolution in the FFP. In this scenario, all IP traffic originated 
from the 192.168.3.xx subnet is discarded. This is implemented by the first rule, with: 



• Layer III protocol type = 0x0800 (IP), and 

• IP source address = 0xC0A803 (192.168.3.xx). 

45 

[0069] Any packet matched is discarded, as specified by ACTION = 0x1 0. However, an exception to this scenario is 
that if there is ICMP traffic originated from the 1 92.1 68.3.xx subnet, they should be switched. This is supported by the 
second rule, with: 

50 • Layer IV protocol type = 0x01 (ICMP), and 

• IP source address = 0xC0A803 (192.168.3.XX) 

[0070] The action of the second rule is 0x2000. With bit 1 3 set, the FFP will not discard the packet. When a packet 
matches both rules, and when the actions are conflicting (discard vs. not discard), the rule with the higher associated 
55 filter masks wins out. In this case, since the first rule's Filter Select value is 0, while the second rule's is 1 , the second 
rule wins the tiebreaker. 

[0071] Another application requiring a more complex traffic permission scheme is discussed below. In this example, 
some application traffic that is not associated with just a Well-Known Port (WKP) is considered. The permission of 
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such traffic is more complicated. In a case when the general traffic is denied, but only a special application is permitted 
it requ.res the permission of all traffic in this type of application. In certain applications, it involves some dynamic ports 
in addition to the application's WKP. 

[0072] For example, a LAN may only permit a certain type of IP telephony traffic in a particular subnet, while denying 
all other traffic in that subnet. The permitted traffic is represented by the standard protocol Session Initiation Protocol 
(SIP). This scenario is represented by the following Access Control List:: 

access-list 122 deny ip 192.168.5.0 0.0.0.255 192.168.5.0 0.0.0.255 
access-list 122 permit ip 192.168.5.0 0.0.0.255 192.168.5.0 0.0.0.255 eq SIP 

[0073] To implement this Access Control List, the following filters masks (Table 6) and rules (Table 7) are necessary: 



15 




Ingress 
Port Mask 


Egress 
Port Mask 


Filter Mask 


20 


0 


0 


0 


0000 0000 0000 0000 0000 0000 0000 0000 
FFFF 0000 0000 0000 0000 0000 0000 FFFF 
FF00 FFFF FF00 0000 0000 0000 0000 0000 
0000 0000 0000 0000 0000 0000 0000 0000 


25 


1 


0 


0 


0000 0000 0000 0000 0000 0000 0000 0000 
FFFF 0000 0000 0000 0000 0000 0000 FFFF 
FF00 FFFF FF00 0000 FFFF 0000 0000 0000 
0000 0000 0000 0000 0000 0000 0000 0000 



TABLE 6 



30 



35 



40 



Filter Select 


Action 


Filter Value 


0 


10 


0000 0000 0000 0000 0000 0000 0000 0000 
0800 0000 0000 0000 0000 0000 0000 C0A8 
0500 C0A8 0500 0000 0000 0000 0000 0000 
0000 0000 0000 0000 0000 0000 0000 0000 


1 


2000 


0000 0000 0000 0000 0000 0000 0000 0000 
0800 0000 0000 0000 0000 0000 0000 C0A8 
0500 C0A8 0500 0000 13C4 0000 0000 0000 
0000 0000 0000 0000 0000 0000 0000 0000 



TABLE 7 



45 



50 



[0074] The second rule will match all packets in the subnet 192.168.5.xx with the destination port number equal to 
5060 (0x1 3C4), which is the WKP for SIP, but all such SIP packets will also match the first rule. Since the second rule 
has a higher Filter Select value, it will win the tiebreaker. Thus the SIP packets will not be discarded 
[0075] However, these two rules are necessary but not sufficient. In a SIP session, the WKP is used only for session 
setup. Once a session is set up, the I P phone conversation is transmitted between two ports other than the WKP These 
ports, known as dynamic ports, are negotiated between the two IP phones during the setup. They vary from call to call 
[0076] The present invention has the capability to capture the SIP session setup messages, and find out about the 
dynamic ports to be used for the voice transmission. Thus two addition rules will be inserted into the rule table to permit 
all the traffic between these two ports. For example, in a session between two IP phones 192 168 5 22 and 
192.168.5.203, if the voice traffic from 192.168.5.22 to 192.168.5.203 uses the port 7001 (0x1 B59), while the traffic 
in the other direction uses the port 71 05 (0x1 BC1 ), the following two rules are also required- 
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Filter Select 


Action 


Filter Value 


5 


1 


2000 


0000 0000 0000 0000 0000 0000 0000 0000 
0800 0000 0000 0000 0000 0000 0000 C0A8 
0516 C0A8 05CB 0000 1B59 0000 0000 0000 
0000 0000 0000 0000 0000 0000 0000 0000 




r 1 
i 


2000 

I 


0000 0000 0000 0000 0000 0000 0000 0000 
i 0800 0000 0000 0000 0000 0000 0000 C0A8 



I 0000 0000 0000 0000 oooo oooo oooo 0000 



TABLE 8 

[0077] These two rules only have the life span of the duration of the call. When the call is disconnected, they will be 
removed from the rule table. On the other hand, the rule regarding the WKP lives as long as the Access Control List 
is in effect. 

[0078] The complement of the previous example is to deny all traffic of a particular application. In applications that 
involve more than the WKP, denial of such traffic requires more than a single rule. In fact, it may require a substantial 
number of rules if the access denial starts when there are a lot of on-going traffic of that application. For example, 
suppose the LAN administrator wants to deny all SIP traffic in a particular subnet. The ACL for that purpose is given 
as follows: 

25 access-list 122 deny ip 192.168.5.0 0.0.0.255 192.168.5.0 0.0.0.255 eq SIP 

[0079] This can be implemented by using the following mask and rule: 



15 



20 



1 



Ingress 
Port Mask 


Egress 
Port Mask 


Filter Mask 


0 


0 


oooo oooo oooo oooo oooo oooo oooo oooo 

FFFF 0000 0000 0000 0000 0000 0000 FFFF 
FFOO FFFF FFOO 0000 FFFF 0000 0000 0000 

oooo oooo oooo oooo oooo oooo oooo oooo 



TABLE 9 



Filter Select 


Action 


Filter Value 


1 


10 


oooo oooo oooo oooo oooo oooo oooo oooo 

0800 0000 0000 0000 0000 0000 0000 C0A8 
0500 C0A8 0500 0000 13C4 0000 0000 0000 

oooo oooo oooo oooo oooo oooo oooo oooo 



TABLE 10 



[0080] However, this rule is not sufficient. Suppose there are several ongoing SIP calls in the LAN already. Since 
each of these calls uses its own dynamic ports, the above rule cannot stop the traffic between these dynamic ports. 
55 in essence, it will prohibit any new call from getting connected, but it does not disconnect any on-going calls. 

[0081] Information regarding the on-going call is required to create new rules to handle this situation. The present 
invention is capable of keeping track of every SIP call, including the dynamic ports used. As soon as the ACL is enforced, 
such information will be used to create the new rules to discard the voice packets between the dynamic ports. For 



12 

ISDOCID: <EP 130O993A2_l_> 



15 



EP 1 300 993 A2 

example, in an on-going call between 192.168.3.42 and 192.168.3.55, the voice traffic from 192.168.3.42 to 
192.168.3.55 uses dynamic port 7510 (0x1D56), while the voice traffic in the other direction uses dynamic port 7530 
(0x1 D6A), the following two rules are required to explicitly discard the voice packets between the two: 



Filter Select 


Action J 


Filter Value 


1 


10 


0000 0000 0000 0000 0000 0000 0000 0000 
U800 0000 0000 0000 0000 0000 0000 C0A8 


0000 0000 0000 0000 0000 0000 0000 0000 


1 


10 


0000 0000 0000 0000 0000 0000 0000 0000 
0800 0000 0000 0000 0000 0000 0000 C0A8 
0537 C0A8 052A 0000 1D6A 0000 0000 0000 
0000 0000 0000 0000 0000 0000 0000 0000 



TABLE 11 



20 



25 



30 



35 



40 



45 



50 



55 



[0082] There is no definitive way of determining how long these rules will stay in the rule table. When the two parties 
talking on the phone hear no more voice from each other, the most likely consequence is to hang up the phone, 
rendering the rules redundant. The rules may be removed from the table after a pre-determined time-out. The rule 
regarding the WKP of SIP stays in the table as long as the ACL is in effect, to prohibit any new call from getting 
connected. 

[0083] The FFP of the present invention provides a powerful tool for controlling network traffic. The FFP is able to 
regulate network traffic according to a specified Access Control List. In summary, most of the access control commands 
can be implemented by FFP in a straightforward manner. The FFP can enable access control based on a flow, which 
is defined as traffic in a specific application, addresses, subnets and other criteria. Among the FFP features, there are 
actions like drop packets and permit packets that control the access according to the matching criteria of the filters. 
With the help of the CPU, access control can also be enabled and disabled dynamically, based on time-of-the-day, 
dates, and other conditions. 

[0084] Coupled with intelligent software in the CPU, the network switch of the present invention is also capable of 
offering Access Control to more complex network traffic. The software has the intelligence to snoop into traffic going 
through the switch , and retrieve information regarding the traffic of various applications, like Voice over I P and streaming 
media. With this capability, the present invention offers policing of traffic flows that are not known a priori 
[0085] Access control of more complex network traffic is discussed below. Filters are setup in the filter table based 
on the Application Layer protocol type, i.e. packets are filtered based on information in the Transport Layer (Layer 4 
in the ISO seven-layer model). After the initial filters are set, the Access Control Unit (ACU) is capable of adding new 
filters into the filter tables when the switch encounters certain types of packets. This dynamic creation of filter rules is 
discussed below with respect to a specific application. 

[0086] The dynamic creation of filter rules can occur, for example, in the setup and processing of Voice over IP (VOIP) 
applications. The process starts with types of packets that are called setup packets. These packets carry information 
regarding the media channels used in the subsequent a VOIP session. Such information belong to the Transport Layer. 
[0087] The ACU is capable of decoding the packet and extracting such Transport Layer information . The ACU creates 
new filters based on the extracted Transport Layer information. Such new filters filter all the media packets (voice or 
video) that pass through the switch. Access control (permit or deny) are then applied to these media packets. 
[0088] In case of permission of media packets, the ACU will remove the filter upon disconnection of the call. In case 
of denial of media packets, the filter will stay in the table indefinitely. Some timeout mechanism is required for the ACU 
to remove the filter. Thus, the present invention allows for dynamic access based on the application and allows for 
control of traffic even when the precise identifiers of packet data are not known initially. 

[0089] The above-discussed configuration of the invention is, in a preferred embodiment, embodied on a semicon- 
ductor substrate, such as silicon, with appropriate semiconductor manufacturing techniques and based upon a circuit 
layout which would, based upon the embodiments discussed above, be apparent to those skilled in the art. A person 
of skill in the art with respect to semiconductor design and manufacturing would be able to implement the various 
modules, interfaces, and tables, buffers, etc. of the present invention onto a single semiconductor substrate, based 
upon the architectural description discussed above. It would also be within the scope of the invention to implement the 
disclosed elements of the invention in discrete electronic components, thereby taking advantage of the functional as- 
pects of the invention without maximizing the advantages through the use of a single semiconductor substrate. 
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[0090] Although the invention has been described based upon these preferred embodiments, it would be apparent 
to those of skilled in the art that certain modifications, variations, and alternative constructions would be apparent, 
while remaining within the spirit and scope of the invention. In order to determine the metes and bounds of the invention, 
therefore, reference shoukU)e made to the appended claims. 



Claims 

1 . A network switch for network communications, said network switch comprising: 

a data port interface, said data port interface supporting a plurality of data ports transmitting and receiving data; 
a CPU interface, said CPU interface configured to communicate with a CPU; 

a memory management unit, said memory management unit including a memory interface for communicating 
data from said data port interface to switch memory; and 
15 a communication channel, communicating data and messaging information between said data port interface, 

the CPU interface, said switch memory, and said memory management unit; 

wherein said data port interface further comprises an access control unit that filters the data coming into the 
data port interface and takes selective action on the data by applying a set of filter rules such that access to the 
20 switch is controlled by the set of filter rules. 

2. A network switch as recited in claim 1 , wherein said access control unit is programmable by inputs from the CPU 
through the CPU interface. 

25 3. a network switch as recited in claim 1 , wherein said data port interface includes a filter mask table interface and 
a filter rules table thereupon, said set of filter rules being contained in the filter rules table, and wherein said access 
control unit applies a filter mask to a packet incoming thereto, providing a filter result, wherein said filter result is 
applied to the filter rules in said filter rules table, and wherein action is taken on the data based upon the filtering 
result. 

30 

4. A network switch as recited in claim 3, wherein said data port interface, CPU interface, memory management unit, 
communications channel and said access control unit are implemented on a common semiconductor substrate. 

5. A network switch as recited in one of claims t and 4, wherein said access control filter comprises a fast filtering 
35 processor. 

6. A network switch as recited in claim 1 , wherein the access control unit controls access to the switch by incoming 
data independent of the CPU interface, and therefore without communicating with the CPU. 

40 7. a network switch as recited in claim 1 , wherein the access control unit controls access to the switch by incoming 
data in conjunction with communication with the CPU through the CPU interface. 

8. A network switch as recited in claim 7, wherein the CPU changes filter rules of the set of filter rules based on 
access control list set in the CPU. 

45 

9. A network switch as recited in claim 1 , wherein each filter rule of the set of filter rules has an associated index and 
conflicting filtering results based on the application of the filter rules are resolved through the associated indices 
of the filter rules. 

50 10. A method of handling data packets in a network switch, said method comprising: 
placing incoming packets into an input queue; 

filtering the incoming packet through application of a set of filter rules by an access control unit in order to 
determine if the incoming packet should have access through the network switch; and 
55 discarding, forwarding, or modifying the packet based upon the application of the set of filter rules. 

11. A method as recited in claim 10, wherein the method further comprises receiving the set of filter rules through 
communication with a CPU through a CPU interface. 
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12. A method as recited in claim 1 1 , wherein the method further comprises updating filter rules of the set of filter rules 
by the CPU based on an access control list set in the CPU. 

13. A method as recited id claim 12, wherein the method further comprises setting initial filter rules and said step of 
updating filter rules comprises adding new filter rules to the initial filter rules. 

14. A method as recited in claim 13, wherein the step of adding new filter rules to the initial filter rules occurs when 
certain types of packets are received and processed in the network switch. 
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method further comprises resolving conflicting filtering results based on the application of the filter rules through 
the associated indices of the filter rules. 

16. A network switch for handling data packets comprising: 

means for placing incoming packets into an input queue; 

means for filtering the incoming packet through application of a set of filter rules by an access control unit in 

order to determine if the incoming packet should have access through the network switch; and 

means for discarding, forwarding, or modifying the packet based upon the application of the set of filter rules. 

1 7. A network switch as recited in claim 1 6, further comprising means for receiving the set of filter rules through com- 
munication with a CPU through a CPU interface. 

18. A network switch as recited in claim 1 6, further comprising means for updating filter rules of the set of filter rules 
by the CPU based on an access control list set in the CPU. 

19. A network switch as recited in claim 1 6, further comprising means for updating filter rules of the set of filter rules 
by the CPU based on an access control list set in the CPU. 

20. A network switch as recited in claim 1 9, further comprising means for setting initial filter rules and said means for 
updating filter rules comprises means for adding new filter rules to the initial filter rules. 

21 . A method as recited in claim 20, wherein the means for adding new filter rules to the initial filter rules is configured 
to add new filter rules when certain types of packets are received and processed in the network switch. 

22. A network switch as recited in claim 14, wherein each filter rule of the set of filter rules has an associated index 
and the network switch further comprises means for resolving conflicting filtering results based on the application 
of the filter rules through the associated indices of the filter rules. 
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